Eur paisches 
Patentamt 



Eur pean 
Patent Office 



Office eur peen 
des brevets 



Beschei n i g u ng Certificate 



Attestation 



Die angehefteten Unterla- 
gen stimmen mit der 
ursprunglich eingereichten 
Fassung der auf dem nach- 
sten Blatt bezeichneten 
europaischen Paten tan mel- 
dung uberein. 



The attached documents Les documents fixes a 
are exact copies of the cette attestation sont 

European patent application conformes a la version 
described on the following initialement deposee de 
page, as originally filed. la demande de brevet 

europeen specifi^e ^ la 
page suivante. 



Patentanmeidung Nr. Patent application No. Demande de brevet n*" 

03368021.6 



Der Prasldent des Europaischen Patentamts: 
Im Auftrag 

For the President of the European Patent Office 
Le President de {'Office europeen des brevets 

P.O. 



R C van Dijk 



EPA/EPO/OEB Form 1014.1 - 02.2000 7001014 



1 
1 




Europaisches 
Pat ntamt 



Eur pean 
Pat nt Office 



Office europeen 
des br v ts 



Anmeldung Nr: 

Application no.: 03368021.6 



Demande no: 



Anmel detag: 
Date of fning: 
Date de d^pot: 



10.03.03 



Anmel der/AppI 1cant( s)/Demandeur( s): 

INTERNATIONAL BUSINESS MACHINES CORPORATION 



Armonk, NY 10504 
ETATS-UNIS D'AMERIQUE 

Bezelchnung der Erf 1 ndung/Tl t1 e of the 1 nvent1on/Tl tre de 1' Invention: 
(Falls die Bezelchnung der Erflndung nicht angegeben 1st, slehe Beschrel bung. 
If no title Is shown please refer to the description. 
SI aucun titre n'est 1nd1qu6 se referer d la description.) 

A method of authenticating digitally encoded products without private key sharing 

In Anspruch genommene Prlorlat(en) / Priori ty( les) claimed /Pr1or1t6(s) 
revend1qu6e( s) 

Staat/Tag/Aktenzelchen/State/Date/Fl le no. /Pays/Da te/Nuni6ro de d^pot: 



Internationale Patentkl assi f 1 katlon/Internatlonal Patent Classification/ 
Classification Internationale des brevets: 

G06F1/00 

Am Anmel detag benannte Vertrags taa ten/Con tracti ng states designated at date of 
f1l1ng/Etats contractants d^slgn^es lors du d^pot: 

AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL 
PT RO SE SI SK TR LI 



03368021.6 

EPA/EPO/OEB Form 1014.2 - 01.2000 7001014 



2 



FR920030006EP1 



1 



A METHOD OF AUTHENTXCATJN6 DIGITALLY ENCODED PRODUCTS 
WITHOUT PRIVATE KEY SHARING 

Technical field 

The present invention relates to the data processing 
5 field, and more specifically to a method and a corresponding 
system for authenticating digitally encoded products. 

Backg-round art 

Authentication of digital encoded products (such as 
software programs) is commonplace in modern data processing 
10 infrastructures. The authentication process is used to certify 
the identity of an entity from which any product is received . 
The need of authenticated products is particularly acute in 
environments (typically based on the Internet) that are open 
and then allow an uncontrolled access thereto. For example, a 
15 software distribution application requires the authentication 
of any applet used to perform the operations needed for 
installing the desired software products on target computers; 
in this way, the origin of the applet can be verified (by a 
user of the target computer) before authorizing the execution 

20 of potentially dangerous operations. 

Generally, the authentication process involves the 
generation of a digital signature using a private key; a 
trusted certification authority guarantees the identity of the 
owner of the private key by means of a corresponding digital 

25 certificate. In order to increase security of the 
authentication process, the private key is commonly encrypted 
and protected by a password that must be typed during a 
signing procedure. The owner of the private key must take all 
the precautions required to prevent any loss or disclosure of 

30 the password, which can result in an unauthorized and 
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malicious use of the private key (for example, with the 
distribution of harmful code by a hacker pretending to be the 
owner of the private key) . 

However, in many practical situations access to the 
5 private key must be granted to several persons; for example, a 
typical scenario is the authentication of . the software 
products that are routinely delivered by different teams of a 
software development laboratory in a large corporation. In the 
above-mentioned situations, it is unavoidable to share the 
10 password for accessing the private key among a high number of 
persons. However, this uncontrolled dissemination of sensitive 
information can jeopardize the security of the authentication 
process. Particularly, the risk of misuse of the private key 
is strongly increased; moreover, the actual use of the private 
15 key by the different persons cannot be tracked in any way. 

At the same time, the control of the accesses to the 
private key is very critical. In fact, the revocation of an 
authorization granted to a specific person involves the 
generation of a new access password and its distribution to 
20 all the (still authorized) persons. For example, this process 
must be performed whenever a person has been transferred to a 
different department or has left the company. However, the 
operations described above are very complex, time consxuning 
and prone to security breach. 
25 Vice-versa, limiting the access to the private key 

involves the need of having multiple digital certificates with 
corresponding private keys (for example, one for every team) . 
However, this approach is detrimental to the corporate image 
on the marketplace; moreover, it increases the costs of buying 
30 and renewing the different digital certificates. The security 
problems are also exacerbated by the proliferation of the 
sensitive information to be protected. 

An additional drawback is due to the fact that the 
signing procedure requires the typing of the access password 
35 for each product to be authenticated. As a consequence, the 
authentication process cannot be unattended. 
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Alternative approaches supported by the signing tools 
known in the art are not tenable. For exaunple, some signing 
tools support a command line interface that allows passing the 
access password as a parameter; in this case, the access 
5 password can be inserted in an instruction of a script calling 
the signing tool. Different signing tools make it possible to 
import the private key from a configuration registry. However, 
those solutions are unacceptable, because they would involve 
the dissemination of the private key without any control. 



10 Stunmazir of the Invention 

It is an object of the present invention to provide a 
method and a corresponding system for authenticating digitally 
encoded products that do not require the sharing of sensitive 
information used to certify the origin of the products. 
15 It is another object of the present invention to 

increase the security of the authentication process, so as to 
reduce the risks of any misuse of the sensitive information. 

It is yet another object of the present invention to 
allow tracking the actual iTse of the sensitive inf ormation ' by 
20 different authorized users . 

Moreover, it is an object of the present invention to 
centralize the control of the authentication process. 

It is another object of the present invention to restrict 
the access to the sensitive information, without requiring its 
25 proliferation. 

It is yet another object of the present invention to 
support an unattended authentication process. 

The accomplishment of these and other related objects is 
achieved by a method of authenticating a digitally encoded 
30 product being originated by an entity having at least one 
authorized subject, the method including the steps of: a 
client system transmitting a request of authentication of the 
product to a server system, the server system verifying 
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whether the request is received from an authorized subject, 
and responsive to a positive verification certifying that the 
product originates from the entity using sensitive information 
of the entity stored on the server system, and returning a 
5 representation of the certification to the client system. 

The present invention also provides a computer program 
application for performing the method, and corresponding 
computer programs running on the client system and on the 
server system, respectively; program products storing these 
10 computer programs are also encompassed. 

Moreover,' - the- invention provides a structure- for 
implementing the method; a client system and a server system 
for use in the structure are also included. 

The novel features believed to be characteristic of this 
15 invention are set forth in the appended claims . The invention 
itself, however, as well as these and other related objects 
and advantages thereof, will be best understood by reference 
to the following detailed description to be read in 
conjunction with the accompanying drawings. 



20 Bx^leC description of the drawings 



Figure la is a schematic block diagram of a data 

processing infrastructure in which the 
method of the invention is applicable; 
Figure lb shows the functional blocks of a generic 

computer of the system; 
Figure 2 depicts the main software components used 

to implement the methods- 
Figures 3a-3b illustrate an activity diagram describing 

the logic flow of "the method. 



Detiailed description of the preferred embodiment 



With reference in particular to Figure la, a distributed 
data processing infrastructure 100 is shown. The structure 100 
25 implements an automated environment for building packages in a 
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software distribution application. Each software package 
embeds a copy of one or more products to be installed on 
target computers (not shown in the figure) • The software 
package can include one or more applets (for example, written 
5 in the Java language) ; each applet consists of a small program 
designed to run only from within another application (and not 
directly from an operating system) , such as from within a web 
browser equipped with a Java Virtual Machine. 

The applet must be classified as "'trusted", in order to be 
10 authorized to perform the operations required by the software 
distribution application --..(for. ..example/ open network 
connections, read system inf oirmation, update files or run 
executables) . In fact, regular applets are executed by default 
in a controlled environment (referred to as a "sandbox"), 
15 wherein potentially dangerous operations are denied. 
Conversely, a trusted applet is given special privileges that 
allow performing those operations. In order to be classified 
as trusted, the applet must be authenticated; in this way, a 
user of the target computer is guaranteed of the origin of the 
20 applet when prompted to grant the special privileges. 

For this purpose, the structure 100 includes several 
client computers 105, whicK are responsible to build the 
software packages to be distributed; a user can log on each 
client computer 105 specifying his/her user identifier 
25 (userlD) and a personal password. A server computer 110 is 
dedicated to authenticate the applets associated with 
different software packages; access to the server computer 110 
is restricted to one or more system administrators (by means 
of corresponding passwords) . --The- client computers 105 and the 
30 server computer 110 are coupled through a network 115; the 
network 115 consists of a trusted structure, such as a private 
Local Area Network (LAN) of a software development laboratory. 

The authentication of the applets is based on a Public Key 
Infrastructure (PKI) . The PKI leverages an asymmetric 
35 encryption technique involving the use of a (non-confidential) 
public key and a (confidential) private key. One of the keys 
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(either the public one or the private one) is used to encrypt 
an original message (i.e., to transform the original message 
in an apparently unintelligible form) ; the other key is used 
to decipher the encrypted message in order to obtain the 
5 original message. The keys are generated so that it is 
computationally unfeasible to obtain the private key from the 
public key. 

A Certification Authority (CA) garantees the identity of 
the owner of the pair of keys (the development laboratory in 
10 the example at issue) by means of a corresponding digital 
- certificate. The digital certificate includes information 
identifying the owner (such as name, address, and the like) , 
his/her public key, and the name of the certification 
authority. The digital certificate is digitally signed by the 
15 certification authority. 

The digital signature of a message is created generating a 
hash value of the message. The hash value consists of a 
pre-set number of bits, lower than the one required to encode 
the message directly; nevertheless, the hash value is 
20 substantially unique for the message (that is, any change in 
the message generates a different hash value) . The hash value 
is - obtained using a one-way function; so that it is 
computationally unfeasible to obtain the message from the hash 
value. The digital signature is then created by encrypting the 
25 hash value with the private key of a sender. A receiver of the 
(signed) message can validate the same simply generating the 
hash value of the message and comparing this hash value with 
the one extracted from the digital signature using the public 
key of the sender. In this way, the receiver verifies that the 
30 original message has not been corrupted (integrity) and that 
it has been actually sent by the entity identified in the 
digital certificate (authenticity) . 

Therefore, the digital certificate issued by the 
certification authority guarantees that the owner of the 
35 private/public keys pair is actually the entity identified in 
the digital certificate. The identity of the certification 
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authority is in turn guaranteed by an upper level 
certification authority, up to a main certification authority 
generally trusted. 

In the present application, any applet is authenticated by 
5 the development laboratory generating a digital signature 
thereof using the respective private key. The digital 
signature and the digital certificate of the development 
laboratory are then attached to the software package. 
Therefore, the user of any target computer can verify that the 
10 applet has been actually delivered by the development 
laboratory (identified in the digital certificate) . 

However, the concepts of the present invention are also 
applicable when the structure has another architecture, when a 
single client computer or two or more server computers are 
15 envisaged, or when the access to each client and server 
computer is controlled in another way (for example, using a 
hardware key) . Similar considerations apply if the software 
packages are authenticated with a different technique, or ,if 
the structure is used in another application; for example, the 
20 solution of the invention can be exploited by a generic entity 
to authenticate equivalent program code, software drivers, 
license certificates, or more generally to authenticate any 
digitally encoded product. 

A shown in Figure lb, a generic computer of the structure 
25 {client or server) is formed by several units that are 
connected in parallel to a communication bus 150. In detail, a 
microprocessor (jiiP) 155 controls operation of the computer, a 
(Random Access Memory) RAM 160 is directly used as a working 
memory by the microprocessor 155, and a Read Only Memory (ROM) 
30 165 stores basic code for a bootstrap of the computer. Several 
peripheral units are further connected to the bus 150 (by 
means of respective interfaces) . Particularly, a mass memory 
consists of a magnetic hard-disk 170 and a driver 175 for 
reading CD-ROMs 180. Moreover, the computer includes input 
35 devices 185 (for example, a keyboard and a mouse) , and output 
devices 190 (for example, a monitor and a printer) . A network 
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Interface Card (NIC) 195 is used to connect the computer in 
the network. 

However, the concepts of the present invention are also 
applicable when the (client and/or server) computers have a 
5 different structure or include other units. Similar 
considerations apply if the computers are replaced with 
equivalent logic and/or physic systems; for example, each 
computer can consist of a virtual machine or can be 
implemented with two or more distinct machines (such as a 
10 front-end and a back-end) • 

Considering now Figure 2, the main software . components 
used in the structure described above are illustrated. The 
information (programs and data) is typically stored on the 
hard-disks of the client and server computers; the information 

15 is loaded (at least partially) into the respective working 
memories when the programs are running, together with the 
operating systems and other application programs (not shown in 
the figure) ♦ The programs are initially installed onto the 
hard-disks from CD-ROMs ♦ 

20 Particularly, a building tool 205 (typically including a 

compiler, a linker, and so on) is installed on each client 
computer • - The- - building tool 205~ accesses a source code 
repository 210 storing software products, instructions and 
applets to be distributed to the target computers ♦ The 

25 building tool 205 further controls a module 215, which is used 
to submit requests of authentication of specific applets to 
the server computer. For this purpose, the submitting module 
215 interfaces with the client component 22 0 of a remote shell 
(RSH or REMSK) ; the remote shell -client 220 allows invoking 

30 remote commands on the server computer (passing input 
parameters and receiving output results directly) . As 
described in detail in the following, the remote commands 
invoked on the server computer return corresponding signed 
applets 225 to the client computer. The building tool 205 

35 transforms the source code stored in the repository 210 into 
executables, which are then bundled (together with the signed 
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applets 225) so as to generate software packages 230 (that are 
provided to the target computers) . 

Moving now to the seirver computer, an RSH deamon 235 
cooperates with the remote shell client 220; the deamon 235 
5 consists of a program that cannot be invoked explicitly, but 
runs in the background waiting for some conditions to occur. 
The decimon 235 implements several security features. In 
detail, all the Remote Copy (CRP) services are disabled; in 
this way, the downloading of sensitive information from or. the 

10 uploading of harmful code to the server computer are 

prevented. Moreover, the deamon 235 accesses an allowed 

command list 240 and a security file 245. 

The list 240 specifies the remote commajids that can be 
executed by the deamon 235; typically, the allowed command 

15 list 240 includes one or more remote commands for satisfying 
different requests of authentication from the client computers 
and an additional remote command for verifying that the server 
computer has been properly configured to allow a specific 
client computer to connect. 

20 On the other hand, the security file 245 specifies the 

client computers and the users that are authorized to request 
the authentication of app-tets to ^the server computer.; for 
example, each authorized subject is identified by a user 
identifier followed by an address of the client computer where 

25 the user is logged on. 

Each remote command that can be invoked on the server 
computer (specified in the allowed command list 240) consists 
of a script 250, which is called by the deamon 235. The 
scripts 250 interface with different signing tools 255 (for 

30 example, a script SCRa for the Signtool of Netscape and a 
script SCRb for the Authenticode of Microsoft). All the 
signing tools 255 access a digital certificate 260 and a 
corresponding private key 255; the private key is protected by 
an access password (only known to the system administrator) . 
35 Each tool 255 digitally signs the applets received from the 
client corr^uters; the signed applets are returned to the 
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client computers through the deamon 235. The deamon 235 
further controls the storing of information relating to the 
received requests in a log 27 0 (for example, date and time, 
user, client computer, remote command, security exceptions, 
5 error messages, and the like) , 

However, the concepts of the present invention are also 
applicable when the authorized addresses and the authorized 
users are not-correlated to each other, when the security file 
is replaced with equivalent information indicating the 
10 authorized subjets, or when a different number of scripts are 
-- supported (down - to 'a -single one); alternatively,- only., the 
private key is stored on the server computer, or multiple 
digital certificates with the corresponding private keys are 
available (for example, for different companies of a holding) . 
15 Similar considerations apply if the whole application 
(programs on the client computer and on the server computer) 
and the corresponding data are structured in a different 
manner, if other modules or functions are provided, and the 
like. 

20 Moving now to Figures 3a-3b, an activity diagram 

describing the logic of a method 300 that implements a process 
of building a software package is illustrated. The process 
begins at the black start circle 3 03 in the swim-lane of a 
generic client computer. The source code to be distributed is 

25 selected at block 306 (from the corresponding repository) . 
Passing to block 309, the files defining the associated applet 
intended to be executed on each target computer are extracted 
from the source code repository. The method continues to block 
312, wherein the files of the applet are compiled and packed 

30 in an archive, typically consisting of a file conforming to 
the tar (Tape ARchive) format. Descending into block 315, a 
request of authentication of the applet is submitted to the 
server computer. For this purpose, the tar file is sent to a 
standard input channel (stdin) of the remote shell client; the 

35 desired remote command is then invoked on the server computer 
(through the remote shell client) . 
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The deamon running on the server computer is in a wait 
state at block 324 (in the respective swim-lane) . As soon as 
the remote command is received, the process descends into 
block 327, wherein the deamon retrieves the tar file passed by 
5 the remote shell client. The address of the client computer 
from which the remote command has been invoked is detected at 
block 330. Likewise, the identifier of the user logged on the 
client computer is detected at block 333. The process then 
verifies at block 335 whether the pair address -user" 

10 identifies a subject authorized to invoke remote commands on 
the server computer (i.e.. the pair is included in the 
security file) . If not, the process enters an error condition 
at block 336. Conversely, a test is made at block 339 to 
determine whether the remote command is included in the 

15 allowed command list. If the result of the verification is 
negative, the process enters the error block 33 6. On the 
contrary, when all the security conditions are met the script 
corresponding to the remote command is called at block 349 
(passing the tar file received from the client computer) . 

20 In any case, the process continues to block 352 (either 

from block 33 6 or from block 349) , wherein the information 
relating to the operations" described above is logged on ^the 
server computer. The flow of activities then returns to block 
324, waiting for a next remote command. 

25 Referring back to block 349, if the script called by the 

remote command is SCRa (for the Signtool of Netscape) the 
blocks 355-363 are executed, whereas if the script is SCRb 
(for the Authenticode of Microsoft) the blocks 366-378 are 
executed. 

30 Moving to the swim- lane of the script SCRa, the tar file 

received from the client computer is unpacked at block 355. 
The code of the script SCRa includes . an instruction for 
causing the executing of a signing command by the 
corresponding tool. The location of the files to be signed, 

35 the location of the digital certificate and of the private 
key, an identifier of the digital certificate, and the 
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password for accessing the^ private key are passed to the 
signing tool as parameters; the script SCRa is protected, so 
that only the administrator can read its content (including 
the password for accessing the private key) • In response 
5 thereto, the applet is signed at block 3 61 by the 
corresponding tool . The result of this operation is a 
compressed archive, typically consisting of a file conforming 
to the jar (Java ARchive) format; the jar file includes the 
(original) applet, the digital certificate and the digital 

10 signature of the applet. The flow of activities continues to 
block 363, wherein the signed applet is returned to the client 
computer (with the script SCRa that ends its execution) . For 
this purpose, the signed applet is packed (into a tar file) 
and then sent to a standard output channel (stdout) of the 

15 remote shell client. During the whole activity described above 
(corresponding to the execution of the script SCRa) , messages 
denoting the progress of the different operations are echoed 
to the client computer using a standard error channel 
(stderr) . 

20 Similar operations are executed by the script SCRb. 

Particularly, the tar file received from the client computer 
is unpacked at block 3 66' (in the corresponding swim- lane )\ 
Proceeding to block 369, the files to be signed are compressed 
into a single file, typically conforming to the cab (CABinet) 

25 format. The code of the script SCRb then includes an 
instruction for causing the executing of a signing command by 
the corresponding tool. The name of the cab f ile . to be signed 
is passed to the signing tool as a parameter; moreover, the 
signing command is called specifying an option (-en) that ' 

30 instructs the signing tool to import the digital certificate 
and the private key from a registry of the server computer. 
The registry consists of an archive storing configuration 
information. The digital certificate and the private key are 
included in a private section of the registry, which access is 

35 restricted to the administrator; the information is imported 
into the registry during a configuration process of the server 
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computer (with the password for accessing the private key that 
is required only once during the import step).; The applet is 
then signed at block 375 by the corresponding tool. The 
process continues to block 378, wherein the resulting signed 
5 applet is packed into a tar file and returned to the client 
computer (with the script SCRb that ends its execution) . 

Returning now to the swim-lane of the client computer, 
the remote shell client at block 381 receives the tar file 
(generated by either the script SCRa or the script SCRb) . The 

10 flow of activities continues to block 382, wherein the tar 
file is unpacked and made, available to the building tool. The 
process can now be completed at block 384 with the generation 
of the desired software package. The method then ends at the 
concentric white/black stop circles 387. 

15 In the process described above, whenever a new software 

package must be shipped a user logs on a specific client 
computer configured as a building machine; the users 
authorized to do so and the client computers that they can use 
are predefined in the security file stored on the server 

20 computer. The user can now configure the building tool as 
desired and then run the corresponding process. The building 
process -is completely unattended^ " In fact, the - user - only 
authenticates to the client computer (entering his/her 
identifier and the personal password) during a log-on 

25 procedure. Afterwards, any applet is digitally signed by the 
seirver computer (which automatically retrieves the private key 
stored thereon) without requiring any manual intervention. 

In addition, the authorizations for requesting the 
authentication of products can be controlled centrally by the 

30 administrator in a very simple manner. Particularly, the 
granting or the revoking of an authorization (either to a user 
or to a client computer) is performed simply updating the 
security file stored on the server computer. In any case, once 
the access to the authorized client computers has been denied 

35 to a user and/or the respective userlD has been deleted, that 
user cannot request the authentication of products to the 
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server computer any longer. The security is further increased 
by the fact that the authorized users never have direct access 
to the password for accessing the private key; therefore, no 
sensitive information can be acquired by the users while 
5 authorized to run the building process. 

However, the concepts of the present invention are also 
applicable when different signing tools are supported (for 
example, the JDK of Sun) , when only the private key is 
imported from the registry, or when the digital certificate 

10 and/or the private key are loaded in another private 
configuration memory area of the server computer. • Similar 
considerations apply if an equivalent method is implemented, 
if different file formats are used, and the like. 

Alternatively, the method of the invention is used in a 

15 data processing infrastructure based on an untrusted network, 
such as the Internet. A suggested choice for implementing the 
method is to use the HyperText Transfer Protocol Secure 
(HTTPS) standard. In this way, the information transmitted 
over the Internet is encrypted; moreover, each user logged on 

20 a client computer authenticates to the server computer using a 
corresponding digital certificate. The signing procedure is 
then very similar to the one described above. In detail, the 
client computer transmits the request of authentication 
through a POST method; the corresponding response will include 

25 the signed applet (in a body) and information relating to the 
executed operations (in a header) . On the server . side, a 
Servlet engine or a CGI infrastructure performs all the. 
operations required to manage the signing procedure. 

For example, the alternative embodiment of the invention 

30 described above can be used by distributed development 
laboratories interacting with a single remote server computer. 
Moreover, the server computer can also be managed by an 
external company operating as a service provider for several 
clients (for example, implementing a "^^pay-per-use" policy) . 

35 More generally, the present invention proposes a method 

of authenticating a digitally encoded product; the product has 
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been originated by an entity having one or more authorized 
subjects. In the method of the invention, a client system 
transmits a request of authentication of the product to a 
server system. The server system verifies whether the request 
5 is received from an authorized subject. The following steps 
are executed in response to a positive verification. First of 
all, the server system certifies that the product originates 
from the entity; for this purpose, sensitive information of 
the entity stored on the server system are used. A 

10 representation of the certification is then returned . to the 

client system. ... _ . . _. . 

In the method of the invention the server system performs 
all the operations required to authenticate the products; in 
this way, the sharing of any sensitive information used to 

15 certify the origin of the products is avoided. 

The devised solution increases the securing of the 
authentication process, thereby reducing the risks of any 
misuse of the sensitive information. 

The method of the invention allows tracking the actual 

20 use of the sensitive information by the different authorized 
subjects. 

Moreover, the control of -the authentication process is 
centralized on the server computer; therefore, its management 
is strongly simplified. 
25 The proposed structure makes it possible to restrict the 

access to the sensitive information, without involving its 
proliferation. 

The solution according to the present invention, also 
supports unattended authentication processes . 
30 The preferred embodiment of the invention described above 

offers further advantages . 

Particularly, the subject from which the request of 
authentication is received is verified controlling an address 
of the client computer. 
35 In this way, the use of the private key can be restricted 

to requests coming from predefined computers . 
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In addition or in alternative, the method verifies 
whether the user logged on the client computer is authorized. 

The proposed feature further increases the security of 
the process. 

5 However, the solution of the present invention leads 

itself to be implemented even verifying only the address of 
the client computer or only the user from which the request is 
received. For example, the verification limited to the address 
can be implemented when the access to the client computers is 

10 strongly controlled; conversely, the verification limited to 
the user allows requesting the authentication of products from 
different locations. Alternatively, the verification of the 
subject from which the request is received is based on 
different properties; for example, the server computer can 

15 satisfy the requests only coming from the client computers of 
a specific department. 

The solution according to the present invention is 
specifically designed for an authentication process involving 
the generation of a digital signature of the product with a 

20 private key (which is automatically retrieved on the server 
computer) . 

^ This application is particularly advantageous and -makes 
it possible to provide a completely unattended process (even 
if the application of different authentication techniques is 
25 not excluded) . 

In a specific embodiment of the invention, a password for 
accessing the private key is passed to the signing tool as a 
parameter. 

Alternatively, the private key is imported from a private 
30 configuration memory area of the server computer. 

Both the approaches described above are very simple and 
flexible, but at the same time effective. 

However, the method of the invention is also suitable to 
be implemented with different procedures for retrieving the 
35 private key. For example, in an environment wherein the access 
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to the server computer is strongly controlled, the private key 

can be stored without any access password. 

A way to further improve the solution is to limit the 
commands that can be invoked on the server computer. 
5 This additional feature reduces the risks of any 

unauthorized access to the server computer (and then to the 
private key) . 

In any case, the provision of alternative security 
measures is envisaged. 

10 Advantageously, the solution according to the present 

invention is implemented with a- computer program, which is 
provided as a corresponding product stored on a suitable 
medium. The program has a client-server architecture, with 
different modules running on the client computer and on the 

15 server computer, respectively. Moreover, it should be noted 
that either the component on the client computer or the 
component on the server computer is suitable to be implemented 
and distributed separately. 

Alternatively, the program is pre-loaded onto the; 

20 hard-disks, is sent to the computers through a network 
(typically the Internet) , is broadcast, or more generally is 
provided in any other form directly loadable into the working 
memories of the computers. However, the method according to 
the present invention leads itself to be carried out even with 

25 a hardware structure (for example, integrated in: a chip of 
semiconductor material) . 

Naturally, in order to satisfy local and specific 
requirements, a person skilled in the art may apply to the 
solution described above many modifications and alterations 

30 all of which, however, are included within the scope of 
protection of the invention as defined by the following 
claims . 
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1. A method (300) of authenticating a digitally encoded 
product being originated by an entity having at least' one 
authorized subject, the method including the steps of: 
5 a client system transmitting (315) a request of 

authentication of the product to a server system, 

the server system verifying (330-335) whether the request 
is received from an authorized subject, and responsive to a 
positive verification: 
10 certifying (355-3 61 ; 3 66-375 ) that the product 

originates from the entity using sensitive information of the 
entity stored on the server system, and 

returning (363; 378) a representation of the 
certification to the client system. 

15 2. The method (300) according to claim 1, wherein the step of 
verifying (330-3 35) whether the request is received from an 
authorized subject includes: 

comparing (330,335) an address of the client system with 
an indication of authorized addresses stored on the server 

20 system. 

3. The method (300) according to claim 1 or 2, wherein the 
step of verifying (330-335) whether the request is received 
from an authorized subject includes: 

comparing (333,335) an identifier of a user logged on the 
25 client system with an indication of authorized users stored on 
the server system. 

4. The method (300) according to any claim from 1 to 3, 
wherein the step of certifying ( 3 55-3 61 ; 3 66-375 ) includes: 

automatically retrieving (358; 372) a private key of the 
30 entity stored on the server system, and 
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digitally signing (361; 375) the product using the private 

key. 

5. The method (300) according to claim 4, wherein the step of 
automatically retrieving (358; 372) the private key includes: 

5 calling (358) a signing command passing a password for 

accessing the private key as a parameter. 

6. The method (300) according to claim 4, wherein the step of 
automatically retrieving (358; 372) the private key includes; 

calling (372) a signing command with an option causing 
10 the import of the private key from a private configuration 
memory area of the server system. 

7. The method (300) according to any claim from 1 to 6, 
further including the steps of: 

the client system invoking (315) a remote command on the 
15 server system, 

the server system verifying (339) whether the remote 
command is included in a predefined, list stored on. the server 
system, the list including at least one remote command for 
satisfying the-request of authentication, and ...... ..... 

20 the server system executing (349) the remote command if 

included in the list (333) . 

8. A computer program (205 , 215, 220 ; 235 , 25 0 , 255 ) directly 
loadable into a working memory of a data processing structure 
(100) for performing the method (300) of any claim from 1 to 7 

25 when the program is run on the structure.' 

9. A computer program (205,215,220) directly loadable into a 
working memory of a client system (105) for performing a 
method (300) of authenticating a digitally encoded product 
when the program is run on the client system, the product 

30 being originated by an entity having at least one authorized 
subject, wherein the method includes the steps of; 



FR920030006EP1 



20 



transmitting (315) a request of authentication of the 
product to a server system to cause the server system to 
verify whether the request is received from an authorized 
subject and to certify that the product originates from the 
5 entity using sensitive information of the entity stored on the 
server system in response to a positive verification, and 

receiving (381) a representation of the certification 
from the server system. 

10. A computer program (235,250,255) directly loadable into a 
10 working memory of a seirver system (110) for performing a 
method (300) of authenticating a digitally encoded product 
when the program is run on the server system, the product 
being originated by an entity having at least one authorized 
subject, wherein the method includes the steps of: 
15 receiving (327) a request of authentication of the 

product from a client system, 

verifying (330-335) whether the request is received from 
an authorized subject, and responsive to a positive 
verification: 

20 certifying (355-361;366-375) that the product 

originates from the entity using sensitive information, of the 
entity stored on the server system, and 

returning (363; 378) a representation of the 
certification to the client system. 

25 11. A program product (180) comprising a computer readable 
medium on which the program (205 , 215 , 220 ; 235, 250, 255 ) of any 
claim from 8 to 10 is stored. . 

12. A data processing structure (100) for authenticating a 
digitally encoded product being originated by. an entity having 
30 at least one authorized subject, the structure including at 
least one client system (105) and at least one server system 
(110), wherein each client system has means (205,215,220) for 
transmitting a request of authentication of the product to a 
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server system, and wherein each server system has means 
(235,245) for verifying whether the request is received from 
an authorized subject, and means (250,255) for certifying that 
the product originates from the entity using sensitive 
5 information of the entity stored - on the server system and for 
returning a representation of the certification to the client 
system in response to a positive verification. 

13 • In a data processing structure (100) for authenticating a 
10 digitally encoded product being originated by an entity having 
at least one authorized subject, the structure including at 
least one client system (105) and at least one server system 
(110), a client system having means (205,215,220) for 
transmitting a request of authentication of the product to a 
15 server system to cause the server system to verify whether the 
request is received from an authorized subject and to certify 
that the product originates from the entity using sensitive 
information of the entity stored on the server system in 
response to a positive verification, and means (220) for 
20 receiving a representation of the certification from the 
server system. 

14. In a data processing structure (100) for authenticating a 
digitally encoded product being originated by an entity having 
at least one authorized subject, the structure including at 

25 least one client system (105) and at least one server system 
(110) , a server system having means (235) for receiving a 
request of authentication of the product from a client system, 
means (235,245) for verifying whether the request is received 
from an authorized subject, and means (250,255) for certifying 

30 that the product originates from the entity using sensitive 
information of the entity stored on the server system and for 
returning a representation of the certification to the client 
system in response to a positive verification. 
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A METHOD OF AUTHENTICATING DX6ITAL£iY ENCODED PRODUCTS WITHOUT 

PRIVATE KEY SHARING 

Abstract 

A method and a corresponding system for authenticating 
5 software products are proposed. A digital certificate (260) 
and a corresponding private key (265) required to sign each 
product are stored on a server computer* Whenever a user needs 
to sign a product, he/she logs on a client computer and 
transmits a corresponding request to the server computer. The 

10 server computer verifies whether the request has been received 
from an authorized subject; for example, an address of the 
client computer and an identifier of the user are compared 
with a predefined list (245) . If the result of the 
verification is positive, the product is signed and returned 

15 to the client computer ♦ For this purpose, a script (25 0) 
called on the server computer includes either an instruction 
passing the access password to a signing tool (255) as a 
parameter or an instruction causing the signing tool (255) to 
import the access password from a registry of the server 

20 computer. 
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